1. Field of the Invention
The present invention relates to Device Management (DM) messaging in a communication system. More particularly, the present invention relates to a technique for controlling DM response messages in a communication system.
2. Description of the Related Art
With the growth in ubiquitous communications technologies and systems, devices are increasing in functionality and complexity. However, with the increase in the functionality and complexity of the devices, a need for the management of the devices has developed. To address that need, the Open Mobile Alliance (OMA) established a Device Management (DM) Working Group to specify protocols and mechanisms that achieve management of devices. The OMA DM Working Group has developed the OMA-DM specification, which defines a two-way protocol between a DM server and a DM client associated with a device that is used for remote management of the device. An instance of an association between a DM Sever and a DM Client is referred to as a DM session and may be initiated by either the DM client or the DM server. The DM client resides in the device and the DM server manages the device by invoking commands on the DM client. The DM client processes the command and sends a response back to the DM server. Communication between the server and the client is over Synchronization Markup Language (SyncML). Historically, the devices have been wireless devices, but of late, OMA-DM has begun addressing the remote management needs of wired devices as well. Examples of OMA-DM include the setting of initial configuration information in devices, the subsequent installation and update of persistent information in devices, the retrieval of management information from devices, and the processing of events and alarms generated by devices.
An example of the OMA-DM architecture is described below with reference to FIG. 1.
FIG. 1 illustrates an OMA-DM architecture according to the related art.
Referring to FIG. 1, the OMA-DM architecture includes a DM server 100, a DM client 110 and DM standard Management Objects (MOs) 120. The OMA-DM architecture may include additional structural elements. However, a description of additional structural elements of the OMA-DM architecture is omitted for conciseness.
The DM server 100 and DM client 110, which have been described above, communicate via interfaces DM-1 130 and DM-2 132. DM client 110 communicates via interface DM-5 134 with the DM Standard Objects 120.
The DM protocol defines three standard Management Objects (MOs) 120 that all implementations of a DM Client 110 must support. These DM standard MOs 120 include DM Account (DMAcc) MO 122, Device Information (DevInfo) MO 124 and Device Details (DevDetail) MO 126.
The DMAcc MO 122 is used to manage information pertaining to bootstrapped DM servers 100. For each DM server 100 that has been successfully bootstrapped for DM device 110, the DMAcc MO 122 maintains information on a DM Server Identifier (ID), connectivity information, server address, server and client credentials, etc. The DevInfo MO 124 provides basic information about a device associated with the DM client 110. The basic information includes a device ID, a device manufacturer ID, a model identifier, and language settings. The DevDetail MO 126 provides additional information about the device associated with the DM client 110. The additional information includes device type, Original Equipment Manufacturer (OEM), hardware version, firmware version, software version, an indication of whether the device supports optional features (e.g. large-object handling capability), maximum depth of the management tree, maximum total length of any Uniform Resource ID (URI), and maximum total length of any URI segment.
An example of a communication system employing OMA-DM is described below with reference to FIG. 2.
FIG. 2 illustrates an exemplary communication system employing OMA-DM according to the related art.
Referring to FIG. 2, the exemplary communication system employing OMA-DM may include a wired network 200, a wireless network 202, a wired device 210, a wireless device 212, a DM server 220, and a DM authority 230. Each of the wired device 210 and the wireless device 212 has associated therewith a DM client (not shown). In addition, the DM authority 230 may be an Operations Support System (OSS). In FIG. 2, solid lines represent physical connectivity and dotted lines represent logical connectivity.
The exemplary communication system employing OMA-DM illustrated in FIG. 2 is merely one of a number of possible implementations. For example, one of the wired network 200 and the wireless network 202 may be omitted. Alternatively, the wired network 200 and the wireless network 202 may be combined. Further, while the DM server 220 and the DM authority 230 are shown as connected to the wired network 200, one or both of the DM server 220 and the DM authority 230 may alternatively be connected to the wireless network 202.
To facilitate OMA-DM in the communication system illustrated in FIG. 2, a two-way protocol based on the OMA-DM specification is utilized between the DM server 220 and the DM client associated with wireless device 212, and between the DM server 220 and the DM client associated with the wired device 210. The DM authority 230 may direct the DM operations of the DM client associated with each of the wired device 210 and wireless device 212 via the DM server 220. Only the interaction between the DM server 220 and a DM client associated with each of the wired device 210 and wireless device 212, is within the scope of the OMA-DM specification.
An example of a DM server initiated DM session with a DM client is described below with reference to FIG. 3.
FIG. 3 is a signal diagram for a DM server initiated DM session with a DM client in a communication system according to the related art.
Referring to FIG. 3, the DM server initiated DM session between the DM server 302 and the DM client 304 includes two phases. The first phase is a setup phase 310 and the second phase is a management phase 320. The setup phase 310 includes an exchange of information for authentication and device information. The exchange of information in the setup phase 310 includes three packages, each of which may contain multiple messages, namely Package 0 (312), Package 1 (314), and Package 2 (316). Package 0 (312) is sent from DM server 302 to DM client 304 and includes alert information. Package 1 (314) is sent from DM client 304 to DM server 302. Package 1 (314) includes client initialization information and device information. The client initialization information includes client credentials. Package 2 (316) is sent from DM server 302 to DM client 304. Package 2 (316) includes server initialization information and an initial management operation. The server initialization information includes one or more server credentials.
The management phase 320 includes the exchange of two packages, namely Package 3 (322), and Package 4 (324). Package 3 (322) is sent from DM client 304 to DM server 302. Package 3 (322) includes client response information to the management operation triggered by Package 2 (316). Package 4 (324) is sent from DM server 302 to DM client 304. Package 4 (324) includes at least one of an additional management operation and one or more additional user interaction commands, if the DM session is continued beyond the Package 2 message 316. Additional cycles of a Package 3 message 322 and a Package 4 message 324 may be transmitted between the DM server 302 and DM client 304 until the DM session is terminated.
However, the DM server initiated DM session described above with reference to FIG. 3 was developed under the OMA-DM specification in the context of session oriented management operations via unicast communication. Recently, the OMA, under the aegis of the DM-BroadCAST (BCAST) Birds-of-a-Feather (BoF) interest group, started looking at non-session oriented management operations that enable a trusted DM server to push DM commands to a DM device, without the overhead of establishing and maintaining a session. Such DM commands may hereafter be referred to as out-of-band DM messages or session-less messages.
One technique to push out-of-band DM commands to a DM device, without the overhead of establishing and maintaining a session, is to simultaneously execute DM commands in a broadcast mode on a large number of devices. An exemplary communication system employing DM-BCAST is similar to the communication system described above with reference to FIG. 2. However, a communication system employing DM-BCAST includes a BCAST server (not shown). In operation, an out-of-band DM command to be communicated via BCAST originates at the DM server, is transmitted to a BCAST server, and is then transmitted to a plurality of devices. While this feature can be made use of by any service provider that chooses to use it, the DM-BCAST BoF study group identified specific cases where this capability has certain utility. Such identified use cases include firmware/software updates, audience/network measurements, and device capability control.
The DM protocol has been designed so that a DM client reports back the response/status of any DM command issued by a DM server. However, the DM protocol does not support any mechanism to control the flow of messages from the DM client to the DM server. This is problematic in the broadcast setting as there is a need to regulate the flow of response/status messages back from the DM client to the DM server so as not to overwhelm the DM server with response messages.
An example of a flow of messages from a DM server to DM clients in a broadcast setting are described below with reference to FIG. 4.
FIG. 4 illustrates a flow of messages from a DM server to DM clients in a broadcast setting according to the related art.
Referring to FIG. 4, a DM Request R 400 is sent from DM Server 410 to a BCAST Server 420 for delivery to DM client 1 430-1, DM client 2 430-2 . . . DM Client n 430-n. The DM Request R 400 is sent from BCAST Server 420 to each of DM client 1 430-1, DM client 2 430-2 . . . DM Client n 430-n.
However, the responses from each of DM client 1 430-1, DM client 2 430-2 . . . DM Client n 430-n to DM Request R 400 are sent immediately. Further the responses from each of DM client 1 430-1, DM client 2 430-2 . . . DM Client n 430-n to DM Request R 400 are sent to either a single designated response server (denoted by the RespURI element in the SyncML message) or sent directly to DM Server 410 if no RespURI element is present. The responses from each of DM client 1 430-1, DM client 2 430-2 . . . DM Client n 430-n to DM Request R 400 may not follow the path of DM Request R 400 through the BCAST Server 420.
As a result the DM Server 410 or designated single response server will receive a significant number of effectively simultaneous response messages from a DM Request R 400 from an unknown number of clients.
Therefore, a need exists for an architecture that provides scale-able response handling as well as a mechanism by which the generation of response/status messages from DM clients to a DM server can be controlled.